구성 가이드

JBoss EAP를 독립 실행형 서버로 실행하여 JBoss EAP의 단일 인스턴스를 관리할 수 있습니다.

서버는 일시 중지된 상태로 시작되고 필요한 모든 서비스가 시작될 때까지 요청을 수락하지 않습니다. 필수 서비스가 시작되면 서버가 일반 실행 상태로 전환되고 요청을 수락할 수 있습니다.

이 시작 스크립트는 EAP_HOME/bin/standalone.conf 파일 또는 Windows Server의 standalone.conf. skip를 사용하여 JVM 옵션과 같은 기본 설정을 설정합니다. 이 파일에서 설정을 사용자 지정할 수 있습니다.

JBoss EAP는 기본적으로 standalone.xml 구성 파일을 사용하지만 다른 파일을 사용하여 시작할 수 있습니다.

관리형 도메인 운영 모드에서 JBoss EAP를 실행하여 단일 도메인 컨트롤러를 사용하여 여러 JBoss EAP 인스턴스를 관리할 수 있습니다.

서버는 일시 중단된 상태로 시작하고 필요한 모든 서비스가 시작될 때까지 요청을 수락하지 않습니다. 필수 서비스가 시작되면 서버는 일반 실행 상태로 전환되고 요청을 수락하기 시작합니다.

도메인의 서버 그룹보다 먼저 도메인 컨트롤러를 시작해야 합니다.

이 시작 스크립트는 EAP_HOME/bin/domain.conf 파일 또는 Windows Server의 경우 domain.conf. #159를 사용하여 JVM 옵션과 같은 기본 기본 설정을 설정합니다. 이 파일에서 설정을 사용자 지정할 수 있습니다.

JBoss EAP는 기본적으로 host.xml 호스트 구성 파일을 사용하지만 다른 구성 파일을 사용하여 시작할 수 있습니다.

관리형 도메인을 설정할 때 시작 스크립트에 추가 인수를 전달해야 합니다.

독립 실행형 서버의 대화형 인스턴스 또는 도메인 컨트롤러를 시작한 터미널에서 중지할 수 있습니다.

관리 CLI에 연결하여 관리형 도메인에서 독립 실행형 서버 또는 서버의 실행 중인 인스턴스를 종료할 수 있습니다.

관리형 도메인의 서버에서 JBoss EAP의 인스턴스를 실행하는 경우 shutdown 명령과 함께 --host 인수를 사용하여 종료할 호스트 이름을 지정해야 합니다.

독립 실행형 서버를 사용하여 관리자 전용 모드에서 JBoss EAP 인스턴스를 실행할 수 있습니다.

관리형 도메인에서 도메인 컨트롤러가 관리자 전용 모드로 시작되면 보조 호스트 컨트롤러에서 들어오는 연결을 허용하지 않습니다. 관리자 전용 모드에서 시작된 호스트 컨트롤러는 서버를 시작하지 않습니다.

JBoss EAP 8.0은 서버 작업을 정상적으로 일시 중단하는 일시 중단 모드를 제공합니다. 이렇게 하면 모든 활성 요청이 정상적으로 완료되지만 새 요청을 수락하지 않습니다. 서버가 일시 중지되면 종료되거나 실행 중인 상태로 반환되거나 유지보수를 수행하기 위해 일시 중지된 상태로 되돌릴 수 있습니다.

관리 콘솔 또는 관리 CLI를 사용하여 서버를 일시 중지하고 다시 시작할 수 있습니다.

각 예제에서는 일시 중지하기 전에 요청이 완료될 때까지 최대 60초 동안 기다립니다.

:resume

서버를 중지할 때 적절한 시간 초과 값이 지정된 경우 서버가 정상적으로 종료됩니다. 명령이 실행되면 서버가 일시 중지되고 종료되기 전에 모든 요청이 완료될 때까지 지정된 시간 초과까지 기다립니다.

다음 관리 CLI 명령을 사용하여 서버를 정상적으로 종료합니다. 서버가 활성 요청이 완료될 때까지 대기할 시간 초과 값(초)을 지정합니다. 기본값은 서버를 즉시 종료하는 0 입니다. 값 -1 을 사용하면 서버가 종료되기 전에 모든 활성 요청이 완료될 때까지 무기한 대기합니다.

각 예제에서는 요청을 종료하기 전에 최대 60초 동안 기다립니다.

-Xrs java 인수가 JVM 옵션에 전달되는 경우 또는 전송된 신호가 하나가 아닌 경우와 같이 JVM이 신호 처리를 비활성화하도록 구성된 경우 또는 KILL 신호가 전송되는 경우와 같이 프로세스가 응답할 수 있는 경우 OS 신호를 사용하는 정상 종료는 작동하지 않습니다.

명령을 사용하여 독립 실행형 서버 또는 관리형 도메인 운영 모드에서 JBoss EAP의 RPM 설치를 시작할 수 있습니다. 다음 명령은 RHEL(Red Hat Enterprise Linux) 8 이상 버전과만 호환됩니다.

$ sudo systemctl start eap8-standalone.service

이렇게 하면 기본적으로 standalone.xml 구성 파일을 사용하여 JBoss EAP가 시작됩니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 독립 실행형 서버 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.

$ sudo systemctl start eap8-domain.service

그러면 기본적으로 host.xml 구성 파일을 사용하는 JBoss EAP가 시작됩니다. RPM 서비스 구성 파일에서 속성을 설정하여 다른 관리형 도메인 구성 파일로 JBoss EAP를 시작할 수 있습니다. 자세한 내용은 아래의 RPM 서비스 속성 구성 섹션을 참조하십시오.

이 섹션에서는 JBoss EAP 설치를 위한 RPM 서비스 속성 및 기타 시작 옵션을 구성하는 방법을 설명합니다. 수정 전에 구성 파일을 백업하는 것이 좋습니다.

RPM 설치에 사용 가능한 모든 시작 옵션 목록은 RPM 서비스 구성 속성 섹션을 참조하십시오.

명령을 사용하여 독립 실행형 서버 또는 관리형 도메인 운영 모드에서 JBoss EAP의 RPM 설치를 중지할 수 있습니다. 다음 명령은 RHEL(Red Hat Enterprise Linux) 8 이상 버전과만 호환됩니다.

$ sudo systemctl stop eap8-standalone.service

$ sudo systemctl stop eap8-domain.service

RPM 설치에 사용 가능한 모든 시작 옵션 목록은 RPM 서비스 구성 파일 섹션을 참조하십시오.

add-user 유틸리티 스크립트를 사용하여 관리 사용자를 추가할 수 있습니다.

사용자는 매개 변수를 add-user 스크립트에 전달하여 비대화형으로 생성할 수도 있습니다. 이 접근 방식은 로그 및 기록 파일에 암호가 표시되므로 공유 시스템에서 권장되지 않습니다. 자세한 내용은 비대화형으로 추가 사용자 유틸리티 실행을 참조하십시오.

명령줄에서 인수를 전달하여 add-user 스크립트를 비대화형으로 실행할 수 있습니다. 최소한 사용자 이름과 암호를 제공해야 합니다.

여러 그룹에 속하는 사용자 생성

다음 명령은 guest 및 mgmtgroup 그룹과 함께 관리 사용자 mgmtuser1 을 추가합니다.

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

대체 속성 파일 지정

기본적으로 add-user 스크립트를 사용하여 생성된 사용자 및 그룹 정보는 서버 구성 디렉터리에 있는 속성 파일에 저장됩니다.

사용자 정보는 다음 속성 파일에 저장됩니다.

그룹 정보는 다음 속성 파일에 저장됩니다.

이러한 기본 디렉터리 및 속성 파일 이름은 재정의할 수 있습니다. 다음 명령은 사용자 속성 파일에 다른 이름과 위치를 지정하는 새 사용자를 추가합니다.

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'

새 사용자가 /path/to /standaloneconfig/newname.properties 및/path/to/ domainconfig/newname.properties 에있는 사용자 속성 파일에 추가되었습니다. 이러한 파일이 이미 존재하거나 오류가 표시됩니다.

사용 가능한 모든 추가 사용자 인수 및 용도의 전체 목록은 --help 인수를 사용하거나 Add-user 유틸리티 인수 섹션을 참조하십시오.

add-user 유틸리티 스크립트의 암호 제한 사항은 EAP_HOME/bin/add-user.properties 파일을 사용하여 구성할 수 있습니다.

의도하지 않은 암호를 설정하지 않으려면 키보드의 시스템 키 맵이 올바른지 확인합니다. 기본 시스템 키맵은 en-qwerty 입니다. 이 기본 설정을 변경하고 새 암호를 생성하는 경우 암호가 SimplePasswordStrengthChecker 클래스에 있는 기준을 충족하는지 확인해야 합니다.

기본적으로 JBoss EAP는 약한 암호를 허용하지만 경고를 발행합니다. 지정된 최소 요구 사항을 충족하지 않는 암호를 거부하려면 password.restriction 속성을 REJECT 로 설정합니다.

다음 표에서는 EAP_HOME/bin/add-user.properties 파일에서 구성할 수 있는 추가 암호 요구 사항 설정을 설명합니다.

메시지가 표시되면 사용자 이름을 입력하여 add-user 유틸리티 스크립트를 사용하여 기존 관리 사용자의 설정을 업데이트할 수 있습니다.

$ EAP_HOME/bin/add-user.sh

What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : test-user
User 'test-user' already exists and is enabled, would you like to...
 a) Update the existing user password and roles
 b) Disable the existing user
 c) Type a new username
(a):

이미 존재하는 사용자 이름을 입력하면 다음과 같은 몇 가지 옵션이 제공됩니다.

관리 CLI(명령줄 인터페이스)는 JBoss EAP용 명령줄 관리 툴입니다.

관리 CLI를 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소, 시스템 설정을 구성하고, 기타 관리 작업을 수행합니다. 배치 모드에서 작업을 수행하여 여러 작업을 그룹으로 실행할 수 있습니다.

ls,cd 및 pwd 와 같은 많은 일반적인 터미널 명령을 사용할 수 있습니다. 관리 CLI는 탭 완료도 지원합니다.

명령 및 작업, 구문 및 일괄 처리 모드로 실행되는 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.

관리 CLI 시작

$ EAP_HOME/bin/jboss-cli.sh

실행 중인 서버에 연결

connect

또는 관리 CLI를 시작하고 EAP_HOME/bin/jboss-cli.sh --connect 명령을 사용하여 한 단계로 연결할 수 있습니다.

도움말 표시

일반적인 도움말에는 다음 명령을 사용합니다.

help

명령에 --help 플래그를 사용하여 해당 특정 명령을 사용하는 방법에 대한 지침을 받습니다. 예를 들어 deploy 를 사용하여 정보를 수신하기 위해 다음 명령을 실행합니다.

deploy --help

관리 CLI 종료

quit

시스템 설정 보기

다음 명령은 read-attribute 작업을 사용하여 예제 데이터 소스가 활성화되었는지 여부를 표시합니다.

/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
{
    "outcome" => "success",
    "result" => true
}

관리형 도메인에서 실행하는 경우 명령 앞에 /profile=PROFILE_NAME 을 추가하여 업데이트할 프로필을 지정해야 합니다.

/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)

시스템 설정 업데이트

다음 명령은 write-attribute 작업을 사용하여 예제 데이터 소스를 비활성화합니다.

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)

서버 시작

관리 CLI는 관리형 도메인에서 실행할 때 서버를 시작하고 중지하는 데 사용할 수도 있습니다.

/host=HOST_NAME/server=server-one:start

관리 콘솔은 JBoss EAP를 위한 웹 기반 관리 툴입니다.

관리 콘솔을 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 제거하고, 시스템 설정을 조정하며, 서버 구성을 영구적으로 수정합니다. 관리 콘솔은 사용자가 서버를 다시 시작하거나 다시 로드해야 하는 변경을 수행할 때 실시간 알림을 사용하여 관리 작업을 수행할 수도 있습니다.

관리형 도메인에서 동일한 도메인의 서버 인스턴스 및 서버 그룹은 도메인 컨트롤러의 관리 콘솔에서 중앙 집중식으로 관리됩니다.

기본 관리 포트를 사용하여 로컬 호스트에서 실행되는 JBoss EAP 인스턴스의 경우 http://localhost:9990/console/index.html 에서 웹 브라우저를 통해 관리 콘솔에 액세스할 수 있습니다. 관리 콘솔에 액세스하는 데 필요한 역할이 있는 사용자로 로그인합니다.

관리 콘솔은 JBoss EAP 독립 실행형 서버 또는 관리형 도메인을 탐색하고 관리하기 위한 다음 탭을 제공합니다.

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=true)

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)

HTTP API 끝점은 HTTP 프로토콜을 사용하여 JBoss EAP 관리 계층과 통합하는 관리 클라이언트의 진입점입니다.

HTTP API는 JBoss EAP 관리 콘솔에서 사용되지만 다른 클라이언트에도 통합 기능을 제공합니다. 기본적으로 HTTP API는 http://HOST_NAME:9990/management 에서 액세스할 수 있습니다. 이 URL에는 API에 노출된 원시 속성 및 값이 표시됩니다.

리소스 읽기

HTTP POST 메서드를 사용하여 다른 작업을 읽거나 쓰거나 수행할 수 있지만 GET 요청을 사용하여 일부 읽기 작업을 수행할 수 있습니다. HTTP GET 메서드는 다음 URL 형식을 사용합니다.

http://HOST_NAME:9990/management/PATH_TO_RESOURCE?operation=OPERATION&PARAMETER=VALUE

교체 가능한 모든 값을 요청에 적합한 값으로 교체해야 합니다. 다음 값은 OPERATION 대체 값에 사용할 수 있는 옵션입니다.

다음 예제 URL은 HTTP API를 사용하여 읽기 작업을 수행하는 방법을 보여줍니다.

http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default

기본 HTTP 리스너의 모든 속성 및 해당 값이 표시됩니다.

http://HOST_NAME:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled

이렇게 하면 ExampleDS 데이터 소스에 대해 활성화된 속성 값이 표시됩니다.

리소스 업데이트

HTTP POST 메서드를 사용하여 구성 값을 업데이트하거나 HTTP API를 사용하여 다른 작업을 수행할 수 있습니다. 이러한 작업에 대한 인증을 제공해야 합니다.

다음 예제에서는 HTTP API를 사용하여 리소스를 업데이트하는 방법을 보여줍니다.

$ curl --digest http://HOST_NAME:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"write-attribute", "address":["subsystem","datasources","data-source","ExampleDS"], "name":"enabled", "value":"false", "json.pretty":"1"}'

이렇게 하면 ExampleDS 데이터 소스에 대한 enabled 속성 값이 false 로 업데이트됩니다.

$ curl --digest http://localhost:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"reload"}'

이렇게 하면 서버가 다시 로드됩니다.

HTTP API를 사용하여 JBoss EAP에 애플리케이션을 배포하는 방법에 대한 자세한 내용은 HTTP API를 사용하여 애플리케이션 배포를 참조하십시오.

네이티브 API 엔드포인트는 기본 프로토콜을 사용하여 JBoss EAP 관리 계층과 통합하는 관리 클라이언트의 진입점입니다. 기본 API는 JBoss EAP 관리 CLI에서 사용하지만 다른 클라이언트에도 통합 기능을 제공합니다.

다음 Java 코드는 네이티브 API를 사용하여 Java 코드에서 관리 작업을 실행하는 방법의 예를 보여줍니다.

// Create the management client
import org.jboss.dmr.ModelNode;
import org.jboss.as.controller.client.ModelControllerClient;
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);

// Create the operation request
ModelNode op = new ModelNode();

// Set the operation
op.get("operation").set("read-resource");

// Set the address
ModelNode address = op.get("address");
address.add("subsystem", "undertow");
address.add("server", "default-server");
address.add("http-listener", "default");

// Execute the operation and manipulate the result
ModelNode returnVal = client.execute(op);
System.out.println("Outcome: " + returnVal.get("outcome").toString());
System.out.println("Result: " + returnVal.get("result").toString());

// Close the client
client.close();

독립 실행형 구성 파일은 EAP_HOME/standalone/configuration/ 디렉터리에 있습니다. 사전 정의된 5개의 프로필(기본값, ha, full ,full -ha ,load-balancer) 각각에 대해 별도의 파일이 있습니다. 다음은 JBoss EAP를 시작할 때 관리 CLI를 사용하여 수정할 수 있는 구성 파일의 예입니다.

기본적으로 JBoss EAP를 독립 실행형 서버로 시작하면 standalone.xml 파일이 사용됩니다. 다른 구성으로 JBoss EAP를 시작하려면 --server-config 인수를 사용합니다. 예를 들면 다음과 같습니다.

$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

YAML 파일을 사용하여 독립 실행형 서버 업데이트

YAML 파일을 사용하여 독립 실행형 서버를 구성하면 사용자 지정 프로세스가 외부화되고 서버 업그레이드 속도가 향상됩니다. 이 기능을 사용하면 서버가 읽기 전용 모드로 시작됩니다. 즉, 서버를 다시 시작한 후에는 구성 변경 사항이 유지되지 않습니다.

사용자는 YAML 파일에서 다양한 리소스를 수정할 수 있습니다. YAML 파일에서 지원되는 요소는 다음과 같습니다.

YAML 파일에서는 다음 요소가 지원되지 않습니다.

YAML 루트 노드는 Wildfly-configuration 입니다. 모델 트리에 따라 리소스를 수정할 수 있습니다. 리소스가 이미 존재하는 경우( XML 구성 파일 또는 이전 YAML 파일에 의해 생성됨) 모델 트리를 사용하여 해당 리소스를 업데이트할 수 있습니다. 리소스가 없는 경우 모델 트리를 사용하여 리소스를 생성할 수 있습니다.

wildfly-configuration:
  subsystem:
    datasources:
      jdbc-driver:
        postgresql:
          driver-name: postgresql
          driver-xa-datasource-class-name: org.postgresql.xa.PGXADataSource
          driver-module-name: org.postgresql.jdbc
      data-source:
        PostgreSQLDS:
          enabled: true
          exception-sorter-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
          jndi-name: java:jboss/datasources/PostgreSQLDS
          jta: true
          max-pool-size: 20
          min-pool-size: 0
          connection-url: "jdbc:postgresql://localhost:5432}/demo"
          driver-name: postgresql
          user-name: postgres
          password: postgres
          validate-on-match: true
          background-validation: false
          background-validation-millis: 10000
          flush-strategy: FailingConnectionOnly
          statistics-enable: false
          stale-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
          valid-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
          transaction-isolation: TRANSACTION_READ_COMMITTED

위의 예제에서는 postgresql 라는 jdbc-driver 와 PostgreSQLDS 라는 데이터 소스 를 정의합니다.

관리형 도메인 구성 파일은 EAP_HOME/domain/configuration/ 디렉터리에 있습니다. 다음은 JBoss EAP를 시작할 때 관리 CLI를 사용하여 수정할 수 있는 구성 파일의 예입니다.

기본적으로 관리형 도메인에서 JBoss EAP를 시작하면 host.xml 파일이 사용됩니다. 다른 구성으로 JBoss EAP를 시작하려면 --host-config 인수를 사용합니다. 예를 들면 다음과 같습니다.

$ EAP_HOME/bin/domain.sh --host-config=host-primary.xml

JBoss EAP 서버 구성을 복원하려면 다음 위치에서 데이터를 백업해야 합니다.

서버의 유지 관리 및 관리를 지원하기 위해 JBoss EAP는 시작 시 원본 구성 파일의 타임스탬프가 지정된 버전을 생성합니다.

관리 작업에서 변경한 추가 구성 변경으로 인해 원래 파일이 자동으로 백업되고 참조 및 롤백을 위해 인스턴스의 작업 사본이 보존됩니다. 또한 현재 서버 구성의 지정 시간 복사본인 구성 스냅샷을 가져올 수 있습니다. 이러한 스냅샷은 관리자가 저장하고 로드할 수 있습니다.

다음 예제에서는 standalone.xml 파일을 사용하지만 domain.xml 및 host.xml 파일에 동일한 프로세스가 적용됩니다.

스냅샷 가져오기

관리 CLI를 사용하여 현재 구성의 스냅샷을 만듭니다.

:take-snapshot
{
    "outcome" => "success",
    "result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}

스냅샷 나열

관리 CLI를 사용하여 모든 스냅샷을 나열합니다.

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
        "names" => [
            "20151022-133109702standalone.xml",
            "20151022-132715958standalone.xml"
        ]
    }
}

스냅샷 삭제

관리 CLI를 사용하여 스냅샷을 삭제합니다.

:delete-snapshot(name=20151022-133109702standalone.xml)

스냅샷 또는 자동으로 저장된 구성 버전을 사용하여 서버를 시작할 수 있습니다.

JBoss EAP를 사용하여 실행 중인 시스템의 구성 변경 사항을 추적할 수 있습니다. 이를 통해 관리자는 다른 권한 있는 사용자가 변경한 구성 변경 내역을 볼 수 있습니다.

관리 CLI 또는 관리 콘솔에서 추적을 활성화하고 구성 변경 사항을 볼 수 있습니다.

관리 CLI에서 구성 변경 사항 추적 및 보기

구성 변경 사항을 추적하려면 다음 관리 CLI 명령을 사용합니다. max-history 특성을 사용하여 저장할 항목 수를 지정할 수 있습니다.

/subsystem=core-management/service=configuration-changes:add(max-history=20)

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:add(max-history=20)

최신 구성 변경 목록을 보려면 다음 관리 CLI 명령을 사용합니다.

/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/server=SERVER_NAME/subsystem=core-management/service=configuration-changes:list-changes

그러면 날짜, 원본, 결과 및 작업 세부 정보가 포함된 각 구성 변경 사항이 나열됩니다. 예를 들어 list-changes 명령의 아래 출력은 가장 최근 표시된 구성 변경 사항을 표시합니다.

{
    "outcome" => "success",
    "result" => [
        {
            "operation-date" => "2016-02-12T18:37:00.354Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [],
                "operation" => "reload",
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:34:16.859Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [
                    ("subsystem" => "datasources"),
                    ("data-source" => "ExampleDS")
                ],
                "operation" => "write-attribute",
                "name" => "enabled",
                "value" => false,
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:24:11.670Z",
            "access-mechanism" => "HTTP",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "operation" => "remove",
                "address" => [
                    ("subsystem" => "messaging-activemq"),
                    ("server" => "default"),
                    ("jms-queue" => "ExpiryQueue")
                ],
                "operation-headers" => {"access-mechanism" => "HTTP"}
            }]
        }
    ]
}

이 예에서는 구성에 영향을 준 세 가지 작업의 세부 정보를 나열합니다.

관리 콘솔에서 구성 변경 사항 추적 및 보기

관리 콘솔에서 구성 변경 사항을 추적할 수 있도록 런타임 탭으로 선택하고 서버 또는 호스트로 이동하여 변경 사항을 추적하고 드롭다운에서 구성 변경 사항을 선택합니다. 구성 변경 사항 사용을 클릭하고 최대 기록 값을 제공합니다.

그런 다음 이 페이지의 표에 날짜, 원본, 결과 및 작업 세부 정보가 포함된 각 구성 변경 사항이 나열됩니다.

JBoss EAP에서 표현식을 사용하여 구성에서 리터럴 값 대신 대체 가능한 속성을 정의할 수 있습니다.

standalone*.xml 또는 domain.xml 구성 파일에서 속성 교체를 사용하면 속성이 시스템 속성에 있는 값으로 교체됩니다. 시스템 속성은 EAP 프로필 xml 파일에 정의되거나 명령줄 터미널에서 -D 명령을 입력하여 정의됩니다.

지정된 하위 시스템에서 속성 교체가 허용되는지 확인하려면 다음 명령을 사용하여 하위 시스템 구성에 대한 설명을 표시합니다.

/subsystem=datasources:read-resource-description(recursive=true)

expressions-allowed 속성이 true 로 설정된 경우 속성 교체가 허용됩니다.

표현식은 ${PARAMETER:DEFAULT_VALUE} 형식을 사용합니다. 지정된 매개변수가 설정되면 매개 변수의 값이 사용됩니다. 그렇지 않으면 제공된 기본값이 사용됩니다.

식을 해결하기 위해 지원되는 소스는 시스템 속성 및 환경 변수입니다. 환경 변수를 사용하여 표현식을 확인하는 경우 ${env.LANG} 형식을 사용합니다.

standalone.xml 구성 파일의 다음 예제에서는 jboss.bind.address 매개변수를 설정하지 않는 한 공용 인터페이스에 대한 inet-address 를 127.0.0.1 로 설정합니다.

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

다음 명령을 사용하여 EAP를 독립 실행형 서버로 시작할 때 jboss.bind.address 매개변수를 설정할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

고정 값 대신 고급 식을 사용할 수 있는 식을 중첩할 수 있습니다.You can nest expressions, which allows for more advanced use of expressions in place of fixed values.

중첩 표현식의 형식은 일반 표현식과 유사하지만 하나의 표현식은 다른 표현식에 포함됩니다. 예를 들면 다음과 같습니다.

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

JBoss EAP는 중첩 표현식을 재귀적으로 평가하므로 내부 표현식이 먼저 평가되고 외부 표현식이 평가됩니다. 표현식은 재귀가 될 수 있습니다. 여기서 표현식은 다른 표현식으로 확인되고, 이 표현식은 확인됩니다. 관리 CLI 명령을 제외하고 표현식이 허용되는 모든 곳에 중첩 표현식이 허용됩니다.

데이터 소스 정의 암호가 마스킹된 경우 중첩 표현식을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

배포 설명자 기반 속성 교체는 설명자를 기반으로 속성을 대체하여 애플리케이션 및 빌드 체인에서 환경에 대한 가정을 제거할 수 있습니다.

환경별 구성은 주석 또는 빌드 시스템 스크립트가 아닌 배포 설명자에 지정할 수 있습니다. 파일 또는 명령줄의 매개 변수로 구성을 제공할 수 있습니다.

데이터 소스 연결 매개 변수와 같은 애플리케이션 구성은 일반적으로 개발, 테스트 및 프로덕션 환경에 따라 다릅니다. Jakarta EE 사양에 이러한 구성을 외부화하는 방법이 포함되어 있지 않으므로 이러한 분산은 빌드 시스템 스크립트에 의해 수용되는 경우가 있습니다. JBoss EAP를 사용하면 설명자 기반 속성 교체를 사용하여 외부에서 구성을 관리할 수 있습니다.

spec-descriptor-property-replacement 플래그는 Jakarta EE 설명자 교체를 제어하고 JBoss EAP는 기본적으로 이를 비활성화합니다. 이 기능이 활성화되면 다음 배포 설명자의 속성을 교체할 수 있습니다.

다음 관리 CLI 명령을 사용하여 Jakarta EE 설명자에서 속성 교체를 활성화하거나 비활성화할 수 있습니다.

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

jboss-descriptor-property-replacement 플래그는 JBoss 관련 설명자 교체를 제어하고 JBoss EAP는 기본적으로 이를 활성화합니다. 이 기능이 활성화되면 다음 배포 설명자의 속성을 교체할 수 있습니다.

다음 관리 CLI 명령을 사용하여 JBoss EAP 관련 설명자에서 속성 교체를 활성화하거나 비활성화합니다.

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

annotation-property-replacement 플래그는 주석 내부의 속성 교체를 제어하며 기본적으로 활성화되어 있지 않습니다. 이 기능이 활성화되면 애플리케이션 클래스 내부의 주석 속성의 속성을 교체할 수 있습니다.

다음 관리 CLI 명령을 사용하여 주석에서 속성 교체를 활성화하거나 비활성화합니다.

/subsystem=ee:write-attribute(name="annotation-property-replacement",value=VALUE)

system property 값이 설정된 경우 annotations -property-replacement 를 true 로 설정하여 주석에서 속성 교체를 활성화할 수 있습니다. 예를 들어 시스템 속성을 설정하여 Message Driven Cryostat에서 maxSession 값을 교체할 수 있습니다.

@MessageDriven(mappedName="jms/Queue", activationConfig =  {
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
                                  propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType",
                                  propertyValue = "javax.jms.Queue")
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "${exampleMDB.maxSession:20}")})
    })
public class ExampleMessageDrivenBean implements MessageListener {
...
}

-DexampleMDB.maxSession 시스템 속성을 100 으로 설정할 수 있습니다. 이 시스템 속성을 설정하지 않으면 기본값은 20 입니다.

Git을 사용하여 서버 구성 데이터, 속성 파일 및 배포를 관리하고 유지할 수 있습니다. 이를 통해 이러한 파일의 버전 기록을 관리할 수 있을 뿐만 아니라 하나 이상의 Git 리포지토리를 사용하여 여러 서버 및 노드에서 서버 및 애플리케이션 구성을 공유할 수 있습니다. 이 기능은 기본 구성 디렉터리 레이아웃을 사용하는 독립 실행형 서버에서만 작동합니다.

로컬 Git 리포지토리에서 구성 데이터를 사용하거나 원격 Git 리포지토리에서 데이터를 가져오도록 선택할 수 있습니다. Git 리포지토리는 독립 실행형 서버 콘텐츠의 기본 디렉터리인 jboss.server.base.dir 디렉터리에 구성됩니다. jboss.server.base.dir 디렉터리가 Git을 사용하도록 구성되면 JBoss EAP는 관리 CLI 또는 관리 콘솔을 사용하여 구성에 대한 모든 업데이트를 자동으로 커밋합니다. 구성 파일을 수동으로 편집하여 서버 외부에서 변경한 내용은 커밋되지 않습니다. 그러나 Git CLI를 사용하여 수동 변경 사항을 추가하고 커밋할 수 있습니다. Git CLI를 사용하여 커밋 기록을 보고 분기를 관리하며 콘텐츠를 관리할 수도 있습니다.

이 기능을 사용하려면 서버를 시작할 때 명령줄에서 다음 인수 중 하나 이상을 전달합니다.

로컬 Git 리포지토리 사용

로컬 Git 리포지토리를 사용하려면 --git-repo=local 인수를 사용하여 서버를 시작합니다. 서버를 시작할 때 --git-branch=GIT_BRANCH_NAME 인수를 추가하여 원격 리포지토리에 선택적 분기 또는 태그 이름을 지정할 수도 있습니다. 이 인수는 기존 분기 또는 태그 이름 이름이 없는 경우 생성되지 않기 때문에 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태에 넣습니다. 즉, 향후 커밋은 임의의 분기에 연결되어 있지 않습니다.

다음은 로컬 리포지토리의 1.0.x 분기를 사용하여 서버를 시작하는 명령의 예입니다.

$ EAP_HOME/bin/standalone.sh --git-repo=local --git-branch=1.0.x

로컬 Git 리포지토리를 사용하기 위해 인수로 서버를 시작하면 JBoss EAP는 jboss.server.base.dir 디렉터리가 이미 Git에 대해 구성되어 있는지 확인합니다. 그렇지 않은 경우 JBoss EAP는 기존 구성 콘텐츠를 사용하여 jboss.server.base.dir 디렉터리에 Git 리포지토리를 생성하고 초기화합니다. JBoss EAP는 --git-branch 인수에서 전달하는 분기 이름을 확인합니다. 해당 인수가 전달되지 않으면 master 분기를 확인합니다. 초기화 후 독립 실행형 서버 콘텐츠의 기본 디렉터리에 .git/ 디렉터리 및 .gitignore 파일이 표시됩니다.

원격 Git 리포지토리 사용

원격 Git 리포지토리를 사용하려면 --git-repo=REMOTE_REPO 인수를 사용하여 서버를 시작합니다. 인수 값은 로컬 Git 구성에 수동으로 추가한 URL 또는 원격 별칭일 수 있습니다.

서버를 시작할 때 --git-branch=GIT_BRANCH_NAME 인수를 추가하여 원격 리포지토리에 선택적 분기 또는 태그 이름을 지정할 수도 있습니다. 이 인수는 기존 분기 또는 태그 이름 이름이 없는 경우 생성되지 않기 때문에 지정해야 합니다. 태그 이름을 사용하는 경우 리포지토리를 분리된 HEAD 상태에 넣습니다. 즉, 향후 커밋은 임의의 분기에 연결되어 있지 않습니다.

Git 리포지토리에 인증이 필요한 경우 서버를 시작할 때 --git-auth=AUTH_FILE_URL 인수도 추가해야 합니다. 이 인수는 Git 리포지토리에 연결하는 데 필요한 자격 증명이 포함된 Elytron 구성 파일의 URL이어야 합니다. 다음은 인증에 사용할 수 있는 Elytron 구성을 지정하는 WildFly Client 구성 파일의 예입니다.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="{ElytronAuthClientNamespace}">
    <authentication-rules>
      <rule use-configuration="test-login">
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="test-login">
        <sasl-mechanism-selector selector="BASIC" />
        <set-user-name name="eap-user" />
        <credentials>
          <clear-password password="my_api_key" />
        </credentials>
        <set-mechanism-realm name="testRealm" />
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

다음은 원격 Cryostat - configuration 리포지토리의 1.0.x 분기를 사용하여 전체 프로필로 서버를 시작하고 인증 자격 증명을 포함하는 Elytron 구성 파일에 URL을 전달하는 명령의 예입니다.

$ EAP_HOME/bin/standalone.sh --git-repo=https://github.com/MY_GIT_ID/eap-configuration.git --git-branch=1.0.x --git-auth=file:///home/USER_NAME/github-wildfly-config.xml --server-config=standalone-full.xml

원격 Git 리포지토리를 사용하기 위해 인수로 서버를 시작하면 JBoss EAP는 jboss.server.base.dir 디렉터리가 이미 Git에 대해 구성되어 있는지 확인합니다. 그렇지 않은 경우 JBoss EAP는 jboss.server.base.dir 디렉터리에 기존 구성 파일을 삭제하여 원격 Git 구성 데이터로 교체합니다. JBoss EAP는 --git-branch 인수에서 전달하는 분기 이름을 확인합니다. 해당 인수가 전달되지 않으면 master 분기를 확인합니다. 이 프로세스가 완료되면 독립 실행형 서버 콘텐츠의 기본 디렉터리에 .git/ 디렉터리와 .gitignore 파일이 표시되어야 합니다.

Git을 사용할 때 원격 구성 데이터 게시

관리 CLI publish-configuration 작업을 사용하여 Git 리포지토리 변경 사항을 원격 리포지토리로 내보낼 수 있습니다. JBoss EAP는 서버를 시작할 때 부팅 프로세스 중에 원격 Git 리포지토리에서 구성을 가져오기 때문에 여러 서버에서 구성 데이터를 공유할 수 있습니다. 이 작업은 원격 리포지토리에서만 사용할 수 있습니다. 로컬 리포지토리에서 작동하지 않습니다.

다음 관리 CLI 작업은 구성 데이터를 원격 192.0.2. -configuration 리포지토리에 게시합니다.

:publish-configuration(location="=https://github.com/MY_GIT_ID/eap-configuration.git")
{"outcome" => "success"}

Git에서 스냅샷 사용

Git 커밋 기록을 사용하여 구성 변경 사항을 추적하는 것 외에도 스냅샷을 작성하여 특정 시점에 구성을 유지할 수도 있습니다. 스냅샷을 나열하고 삭제할 수 있습니다.

Git을 사용할 때 스냅샷 생성

스냅샷은 Git에 태그로 저장됩니다. 스냅샷 태그 이름 및 커밋 메시지를 take-snapshot 작업에서 인수로 지정합니다.

다음 관리 CLI 작업은 스냅샷을 사용하여 "snapshot-01" 태그의 이름을 지정합니다.

:take-snapshot(name="snapshot-01", comment="1st snapshot")
{
    "outcome" => "success",
    "result" => "1st snapshot"
}

Git을 사용할 때 스냅샷 나열

list-snapshots 작업을 사용하여 모든 스냅샷 태그를 나열할 수 있습니다.

다음 관리 CLI 작업에는 스냅샷 태그가 나열됩니다.

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "",
        "names" => [
            "snapshot : 1st snapshot",
            "refs/tags/snapshot-01",
            "snapshot2 : 2nd snapshot",
            "refs/tags/snapshot-02"
        ]
    }
}

Git을 사용할 때 스냅샷 삭제

delete-snapshot 작업에 태그 이름을 전달하여 특정 스냅샷을 삭제할 수 있습니다.

다음 관리 CLI 작업은 이름이 "snapshot-01"인 스냅샷을 삭제합니다.

:delete-snapshot(name="snapshot-01")
{"outcome" => "success"}

다음 관리 CLI 명령을 사용하여 파일 시스템 경로를 나열합니다.

ls /path

ls /host=HOST_NAME/server=SERVER_NAME/path

다음 관리 CLI 명령을 사용하여 파일 시스템 경로의 값을 읽습니다.

/path=PATH_NAME:read-resource

/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource

jboss.server.* 또는 jboss.domain.* 로 시작하는 표준 경로의 기본 위치를 덮어쓸 수 있습니다. 이 작업은 다음 두 가지 방법 중 하나로 수행할 수 있습니다.

관리형 도메인의 표준 경로 덮어쓰기

이 예에서 목표는 도메인 파일을 /opt/jboss_eap/domain_data 디렉터리에 저장하고 각 최상위 디렉터리에 사용자 지정 이름을 지정하는 것입니다. 기본 디렉터리 그룹화인 by-server 가 사용됩니다.

이 구성을 달성하기 위해 JBoss EAP를 시작할 때 여러 시스템 속성을 덮어씁니다.

$ EAP_HOME/bin/domain.sh -Djboss.domain.temp.dir=/opt/jboss_eap/domain_data/all_temp -Djboss.domain.log.dir=/opt/jboss_eap/domain_data/all_logs -Djboss.domain.data.dir=/opt/jboss_eap/domain_data/all_data -Djboss.domain.servers.dir=/opt/jboss_eap/domain_data/all_servers

결과 경로 구조는 다음과 같습니다.

/opt/jboss_eap/domain_data/
               ├── all_data
               ├── all_logs
               ├── all_servers
               │   ├── server-one
               │   │   ├── data
               │   │   ├── log
               │   │   └── tmp
               │   └── server-two
               │       ├── data
               │       ├── log
               │       └── tmp
               └── all_temp

관리 CLI 또는 관리 콘솔을 사용하여 사용자 정의 파일 시스템 경로를 추가할 수 있습니다.

그런 다음 구성에서 이 사용자 지정 경로를 사용할 수 있습니다. 예를 들어 아래 로그 처리기는 상대 경로에 사용자 지정 경로를 사용합니다.

<subsystem xmlns="{LoggingSubsystemNamespace}">
  ...
  <periodic-rotating-file-handler name="FILE" autoflush="true">
    <formatter>
      <named-formatter name="PATTERN"/>
    </formatter>
    <file relative-to="my.custom.path" path="server.log"/>
    <suffix value=".yyyy-MM-dd"/>
    <append value="true"/>
  </periodic-rotating-file-handler>
  ...
</subsystem>

기본적으로 비활성화되지만 기본 감사 로깅 구성은 파일에 씁니다.

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="file"/>
        </handlers>
    </logger>
</audit-log>

이 구성은 다음 관리 CLI 명령을 사용하여 읽을 수 있습니다.

/core-service=management/access=audit:read-resource(recursive=true)

독립 실행형 서버에 대한 감사 로깅 활성화를 참조하십시오. ???

기본적으로 비활성화되지만 기본 감사 로깅 구성은 각 호스트와 각 서버에 대해 파일을 작성합니다.

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
        <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="host-file"/>
        </handlers>
    </logger>
    <server-logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="server-file"/>
        </handlers>
    </server-logger>
</audit-log>

이 구성은 다음 관리 CLI 명령을 사용하여 읽을 수 있습니다.

/host=HOST_NAME/core-service=management/access=audit:read-resource(recursive=true)

관리형 도메인에 대한 감사 로깅 활성화를 참조하십시오. ???

감사 로깅은 기본적으로 비활성화되어 있지만 JBoss EAP는 감사 로깅을 위해 파일 처리기로 사전 구성됩니다. 감사 로깅을 활성화하는 관리 CLI 명령은 독립 실행형 서버로 실행 중인지 아니면 관리형 도메인에서 실행 중인지에 따라 달라집니다. 파일 처리기 속성에 대한 관리 감사 로깅 특성을 참조하십시오.

다음 명령은 NATIVE 및 HTTP 감사 로깅을 활성화합니다. Cryostat 감사 로깅을 구성하려면 Enable Cryostat 관리 감사 로깅 을 참조하십시오.

syslog 감사 로깅을 설정하려면 syslog 서버에 관리 감사 로깅 전송을 참조하십시오.

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)

JBoss EAP는 기본적으로 비활성화되어 있지만 audit 로깅을 위한 파일 처리기로 사전 구성됩니다. 감사 로깅을 활성화하는 관리 CLI 명령은 독립 실행형 서버 또는 관리형 도메인으로 실행 중인지에 따라 달라집니다.

NATIVE 또는 HTTP 감사 로깅을 구성하려면 관리 감사 로깅 활성화를 참조하십시오.

/subsystem=jmx/configuration=audit-log:add()
/subsystem=jmx/configuration=audit-log/handler=file:add()

syslog 처리기는 감사 로그 항목이 syslog 서버로 전송되는 매개변수, 특히 syslog 서버의 호스트 이름과 syslog 서버가 수신 대기하는 포트를 지정합니다. 감사 로깅을 syslog 서버로 전송하면 로컬 파일 또는 로컬 syslog 서버에 로깅하는 것보다 더 많은 보안 옵션이 제공됩니다. 여러 syslog 처리기를 정의하고 동시에 활성화할 수 있습니다.

기본적으로 감사 로깅은 활성화된 경우 파일로 출력되도록 사전 구성됩니다. 다음 단계를 사용하여 syslog 서버에 대한 감사 로깅을 설정하고 활성화합니다. syslog 처리기 속성에 대한 관리 감사 로깅 특성을 참조하십시오.

파일에 대한 감사 로그 항목은 텍스트 뷰어 에서 가장 잘 볼 수 있는 반면 syslog 서버로의 출력은 syslog 뷰어 애플리케이션을 사용하여 가장 잘 볼 수 있습니다.

감사 로그 항목은 JSON 형식으로 저장됩니다. 각 로그 항목은 선택적 타임스탬프로 시작한 다음 아래 표의 필드로 시작합니다.

리스너를 JBoss EAP 코어 관리 하위 시스템에 등록하여 서버 라이프사이클 이벤트를 모니터링할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 리스너 예제를 생성하고 등록하는 방법을 보여줍니다.

이제 서버 라이프사이클 이벤트가 위의 SimpleListener 클래스를 기반으로 my-listener-output.txt 파일에 기록됩니다. 예를 들어 관리 CLI에서 :suspend 명령을 실행하면 다음이 my-listener-output.txt 파일에 출력됩니다.

Running state change for STANDALONE_SERVER: normal to suspending
Running state change for STANDALONE_SERVER: suspending to suspended

이는 실행 중 상태가 정상에서 일시 중지됨으로 변경된 후 일시 중지됨 을 나타냅니다.

Cryostat 알림 리스너를 등록하여 서버 라이프사이클 이벤트를 모니터링할 수 있습니다. 다음 단계에서는 이벤트를 파일에 기록하는 예제 리스너를 생성하고 추가하는 방법을 보여줍니다.

이제 서버 라이프사이클 이벤트가 위의 StateNotificationListener 클래스를 기반으로 파일에 기록됩니다. 예를 들어 관리 CLI에서 :suspend 명령을 실행하면 running-notifications.txt 파일에 다음이 출력됩니다.

jmx.attribute.change 5 jboss.root:type=state The attribute 'RunningState' has changed from 'normal' to 'suspending'
jmx.attribute.change 6 jboss.root:type=state The attribute 'RunningState' has changed from 'suspending' to 'suspended'

이는 실행 중 상태가 정상에서 일시 중지됨으로 변경된 후 일시 중지됨 을 나타냅니다.

다음 인터페이스 구성은 기본적으로 설정됩니다.

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

JBoss EAP는 이러한 인터페이스를 127.0.0.1 에 바인딩하지만 이러한 값은 적절한 속성을 설정하여 런타임 시 재정의할 수 있습니다. 예를 들어 다음 명령을 사용하여 JBoss EAP를 독립 실행형 서버로 시작할 때 공용 인터페이스의 inet-address 를 설정할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

또는 server start 명령행에서 -b 스위치를 사용할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -b IP_ADDRESS

위의 명령에서 -b IP_ADDRESS 는 -Djboss.bind.address=IP_ADDRESS 와 동일합니다.

-b 스위치를 사용하여 관리 인터페이스의 inet-address 를 설정할 수도 있습니다.

$ EAP_HOME/bin/standalone.sh -bmanagement=IP_ADDRESS

단일 변수만 설정하려면 jboss.bind.address.management 를 jboss.bind.address.address로 변경할 수 있습니다. -b 스위치 또는 -Djboss.bind.address 를 설정하면 공용 및 관리 인터페이스가 동일한 IP_ADDRESS 를 공유합니다.

서버 시작 옵션에 대한 자세한 내용은 Server Runtime Arguments 를 참조하십시오.

네트워크 인터페이스는 물리적 인터페이스에 대한 논리 이름 및 선택 기준을 지정하여 선언합니다. 선택 기준은 와일드카드 주소를 참조하거나 유효한 일치를 위해 인터페이스 또는 주소에 있어야 하는 하나 이상의 특성 세트를 지정할 수 있습니다. 사용 가능한 모든 인터페이스 선택 기준의 목록은 인터페이스 속성 섹션을 참조하십시오.

인터페이스는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 다음은 인터페이스 추가 및 업데이트의 몇 가지 예입니다. 관리 CLI 명령 다음에 해당 구성 XML이 표시됩니다.

NIC 값을 사용하여 인터페이스 추가

NIC 값이 eth0 인 새 인터페이스를 추가합니다.

/interface=external:add(nic=eth0)

<interface name="external">
   <nic name="eth0"/>
</interface>

여러 조건부 값을 사용하여 인터페이스 추가

작동 중인 경우 올바른 서브넷의 인터페이스/address와 일치하는 새 인터페이스를 추가하고, 멀티캐스트를 지원하며, 지점 간이 아닙니다.

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})

<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

인터페이스 속성 업데이트

이 값을 런타임 시 설정할 수 있도록 jboss.bind.address 속성을 유지하면서 공용 인터페이스의 기본 inet-address 값을 업데이트합니다.

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")

<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>

관리형 도메인의 서버에 인터페이스 추가

/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)

<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>

관리 포트는 JBoss EAP 7에 통합되었습니다. 기본적으로 JBoss EAP 8.0은 관리 CLI에서 사용하는 기본 관리와 웹 기반 관리 콘솔에서 사용하는 HTTP 관리에 모두 포트 9990 을 사용합니다. JBoss EAP 6에서 네이티브 관리 포트로 사용된 포트 9999 는 더 이상 사용되지 않지만 원하는 경우 활성화할 수 있습니다.

관리 콘솔에 HTTPS가 활성화된 경우 기본적으로 포트 9993 이 사용됩니다.

JBoss EAP에는 사전 정의된 5개의 프로필(기본값, ha, full ,full -ha ,load-balancer) 각각에 대해 소켓 바인딩 그룹이 포함되어 있습니다.

기본 포트 및 설명과 같은 기본 소켓 바인딩에 대한 자세한 내용은 기본 소켓 바인딩 그룹 섹션을 참조하십시오.

독립 실행형 서버

독립 실행형 서버로 실행하는 경우 구성 파일별로 하나의 소켓 바인딩 그룹만 정의됩니다. 각 독립 실행형 구성 파일(standalone.xml,standalone-ha.xml,standalone-full.xml,standalone-full-ha.xml )은 해당 프로필에서 사용하는 기술에 대한 소켓 바인딩을 정의합니다.

예를 들어 기본 독립 실행형 구성 파일(standalone.xml)은 아래 소켓 바인딩을 지정합니다.

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

관리형 도메인

관리형 도메인에서 실행하는 경우 모든 소켓 바인딩 그룹이 domain.xml 파일에 정의됩니다. 미리 정의된 소켓 바인딩 그룹이 5개 있습니다.

각 소켓 바인딩 그룹은 해당 프로필에서 사용하는 기술에 대한 소켓 바인딩을 지정합니다. 예를 들어 full-ha-sockets 소켓 바인딩 그룹은 고가용성을 위해 full-ha 프로필에서 사용하는 여러 jgroups 소켓 바인딩을 정의합니다.

<socket-binding-groups>
  <socket-binding-group name="standard-sockets" default-interface="public">
    <!-- Needed for server groups using the 'default' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'ha' profile  -->
    ...
  </socket-binding-group>
  <socket-binding-group name="full-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full' profile  -->
    ...
  </socket-binding-group>
  <socket-binding-group name="full-ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full-ha' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="iiop" interface="unsecure" port="3528"/>
    <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/>
    <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
    <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
    <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
    <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="load-balancer-sockets" default-interface="public">
    <!-- Needed for server groups using the 'load-balancer' profile  -->
    ...
  </socket-binding-group>
</socket-binding-groups>

소켓 바인딩을 정의할 때 포트 및 인터페이스 특성과 멀티캐스트 주소 및 멀티 캐스트 포트 와 같은 멀티 캐스트 설정을 구성할 수 있습니다. 사용 가능한 모든 소켓 바인딩 속성에 대한 자세한 내용은 Socket 바인딩 특성 섹션을 참조하십시오.

소켓 바인딩은 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 다음 단계는 소켓 바인딩 그룹을 추가하고, 소켓 바인딩을 추가하고, 관리 CLI를 사용하여 소켓 바인딩 설정을 구성하는 단계를 진행합니다.

다음 예제에서는 위의 단계가 완료된 후 XML 구성이 표시되는 방법을 보여줍니다.

<socket-binding-groups>
    ...
    <socket-binding-group name="new-sockets" default-interface="public">
        <socket-binding name="new-socket-binding" interface="unsecure" port="1234"/>
    </socket-binding-group>
</socket-binding-groups>

관리 콘솔에서 서버의 소켓 바인딩 이름과 열려 있는 포트를 볼 수 있습니다.

포트 오프셋은 해당 서버의 소켓 바인딩 그룹에 지정된 모든 포트 값에 추가된 숫자 오프셋 값입니다. 이를 통해 서버는 소켓 바인딩 그룹에 정의된 포트 값을 상속하여 동일한 호스트의 다른 서버와 충돌하지 않도록 오프셋을 사용할 수 있습니다. 예를 들어 소켓 바인딩 그룹의 HTTP 포트가 8080 이고 서버에서 100 의 포트 오프셋을 사용하는 경우 HTTP 포트는 8180 입니다.

다음은 관리 CLI를 사용하여 관리형 도메인의 서버에 대해 250 의 포트 오프셋을 설정하는 예입니다.

/host=primary/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

포트 오프셋은 관리형 도메인의 서버와 동일한 호스트에서 여러 독립 실행형 서버를 실행하는 데 사용할 수 있습니다.

jboss.socket.binding.port-offset 속성을 사용하여 독립 실행형 서버를 시작할 때 포트 오프셋을 전달할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100

IPv6 주소를 선호하도록 시작 구성을 업데이트합니다.

다음 예제에서는 시작 구성 파일의 JVM 옵션이 위의 변경 후 어떻게 표시되는지 보여줍니다.

# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
   JAVA_OPTS="$JBOSS_JAVA_SIZING -Djava.net.preferIPv4Stack=false"
   JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv6Addresses=true"
else

구성의 기본 인터페이스 값은 IPv6 주소로 변경할 수 있습니다. 예를 들어 아래 관리 CLI 명령은 관리 인터페이스를 IPv6 루프백 주소(::1)로 설정합니다.

/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:[::1]}")

다음 예제에서는 위의 명령을 실행한 후 XML 구성이 어떻게 보일 수 있는지 보여줍니다.

<interfaces>
    <interface name="management">
        <inet-address value="${jboss.bind.address.management:[::1]}"/>
    </interface>
    ....
</interfaces>

정적 모듈은 애플리케이션 서버의 EAP_HOME/modules/ 디렉터리에 정의됩니다. 각 모듈은 하위 디렉터리로 존재합니다(예: EAP_HOME/modules/com/mysql/ ). 그런 다음 각 모듈 디렉터리에는 기본 설정 파일과 module.xml (JAR) 파일이 포함된 slot 하위 디렉터리가 포함되어 있습니다. 모든 애플리케이션 서버 제공 API는 Jakarta EE API 및 기타 API를 포함하여 정적 모듈로 제공됩니다.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.9" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-j-8.0.33.jar"/>
  </resources>
  <dependencies>
    <module name="java.xml" export="true"/>
    <module name="java.xml.crypto" export="true"/>
    <module name="jdk.xml.dom" export="true"/>
    <module name="jakarta.transaction.api"/>
  </dependencies>
</module>

모듈 이름 com.mysql 은 슬롯 이름을 제외하고 모듈의 디렉터리 구조와 일치해야 합니다.

동일한 타사 라이브러리를 사용하는 동일한 서버에 많은 애플리케이션이 배포되는 경우 사용자 지정 정적 모듈을 생성할 수 있습니다. 각 애플리케이션과 함께 이러한 라이브러리를 번들하는 대신 관리자가 이러한 라이브러리를 포함하는 모듈을 생성하고 설치할 수 있습니다. 그런 다음 애플리케이션은 사용자 지정 정적 모듈에 대한 명시적 종속성을 선언할 수 있습니다.

JBoss EAP 배포에 제공된 모듈은 EAP_HOME/modules 디렉터리 내의 시스템 디렉터리에 있습니다. 이렇게 하면 타사가 제공하는 모듈과 별도로 유지됩니다. JBoss EAP 상단에 계층이 있는 모든 Red Hat 제품도 시스템 디렉터리에 모듈을 설치했습니다.

사용자는 모듈당 하나의 디렉터리를 사용하여 사용자 지정 모듈이 EAP_HOME/modules 디렉터리에 설치되어 있는지 확인해야 합니다. 이렇게 하면 제공된 버전 대신 시스템 디렉터리에 이미 존재하는 모듈의 사용자 지정 버전이 로드됩니다. 이러한 방식으로 사용자 제공 모듈이 시스템 모듈보다 우선합니다.

JBOSS_MODULEPATH 환경 변수를 사용하여 JBoss EAP가 모듈을 검색하는 위치를 변경하는 경우 제품은 지정된 위치 중 하나의 시스템 하위 디렉터리 구조를 찾습니다. 시스템 구조는 JBOSS_MODULEPATH 로 지정된 위치에 있어야 합니다.

module.xml 파일의 resource-root path 요소에서 절대 경로 사용도 지원됩니다. 이렇게 하면 리소스 라이브러리를 EAP_HOME/modules 디렉터리로 이동할 필요 없이 액세스할 수 있습니다.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.9" name="oracle.jdbc">
    <resources>
        <resource-root path="/home/redhat/test.jar"/>
    </resources>
</module>

동적 모듈은 각 JAR(Java Archive) 또는 WAR(Web Archive) 배포에 대해 애플리케이션 서버에서 생성 및 로드하거나 Enterprise Archive(EAR)의 각 하위 배포에 대해 생성 및 로드합니다. 동적 모듈의 이름은 배포된 아카이브의 이름에서 파생됩니다. 배포는 모듈로 로드되므로 종속성을 구성하고 다른 배포에서 종속성으로 사용할 수 있습니다.

모듈은 일반적으로 명시적 또는 암시적 종속성을 사용하는 애플리케이션이 배포되는 경우에만 필요합니다.

애플리케이션 서버에서 기본 모듈 로더를 사용하는 경우 사전 정의된 모듈 세트를 사용할 수 있습니다. 모든 JBoss Modules API를 포함하는 특수 모듈 org.jboss.modules 에서는 항상 사용할 수 있으며 JBoss 모듈에서 제공합니다. 표준 JPMS(Java Platform Module System) 모듈도 표준 이름으로 사용할 수 있습니다.

Java 9 이상에서 사용할 수 있는 플랫폼 모듈 목록은 적절한 JDK 설명서를 참조하십시오.

Java Archive(JAR) 또는 기타 리소스 파일에서 모듈을 생성하여 JBoss EAP의 애플리케이션에서 사용할 수 있도록 할 수 있습니다.

JAR(Java Archive) 또는 기타 리소스 파일에서 모듈을 생성하여 관리 CLI를 사용하여 JBoss EAP의 애플리케이션에서 사용할 수 있도록 할 수 있습니다.

모듈을 수동으로 제거하기 전에 배포된 애플리케이션 또는 서버 구성의 다른 위치(예: 데이터 소스)에는 필요하지 않은지 확인합니다.

모듈 제거 관리 CLI 명령을 사용하여 사용자 지정 모듈을 제거할 수 있습니다.

이 명령을 사용하여 모듈을 추가 및 제거하는 방법에 대한 자세한 내용은 module --help 를 실행합니다.

하위 시스템에서 관리 콘솔 또는 관리 CLI를 사용하여 하위 배포 격리를 활성화하거나 비활성화할 수 있습니다. 기본적으로 하위 배포 격리는 false 로 설정되어 있으며, 이를 통해 하위 배포는 EAR(Enterprise Archive) 배포 내의 다른 하위 배포의 리소스에 액세스할 수 있습니다.

EAR의 하위 배포는 더 이상 다른 하위 배포의 리소스에 액세스할 수 없습니다.

배포는 JBoss EAP 관리 콘솔의 Deployments 탭에서 보고 관리할 수 있습니다.

애플리케이션 배포

Add (+) 버튼을 클릭합니다. 배포를 업로드하거나관리되지 않는 배포를 추가하거나 빈 배포를 생성하여 애플리케이션을 배포 하도록 선택할 수 있습니다. 배포는 기본적으로 활성화되어 있습니다.

애플리케이션 배포 취소

배포를 선택하고 배포 취소 옵션을 선택합니다. JBoss EAP는 콘텐츠 리포지토리에서 배포를 제거합니다.

애플리케이션 비활성화

배포를 선택하고 Disable 옵션을 선택하여 애플리케이션을 비활성화합니다. 이렇게 하면 배포 배포가 취소되지만 콘텐츠 리포지토리에서 제거되지는 않습니다.

애플리케이션 교체

배포를 선택하고 교체 옵션을 선택합니다. 원본과 동일한 이름이 있어야 하는 배포의 새 버전을 선택하고 마침 을 클릭합니다. 이 명령은 원래 버전의 배포를 취소 및 제거한 다음 새 버전을 배포합니다.

JBoss EAP 관리 콘솔의 Deployments 탭에서는 다음을 통해 배포를 보고 관리할 수 있습니다.

XML, zipped 및 내용의 자동 배포를 허용하거나 허용하지 않도록 배포 스캐너를 구성할 수 있습니다. 자동 배포를 비활성화한 경우 배포 작업을 트리거하려면 마커 파일을 수동으로 생성해야 합니다. 사용 가능한 마커 파일 유형 및 용도에 대한 자세한 내용은 Deployment Scanner Marker Files 섹션을 참조하십시오.

기본적으로 XML 및 zipped 콘텐츠에 대한 자동 배포가 활성화됩니다. 각 콘텐츠 유형에 대한 자동 배포 구성에 대한 자세한 내용은 배포 스캐너 구성을 참조하십시오.

애플리케이션 배포

콘텐츠를 배포 폴더에 복사합니다.

$ cp /path/to/test-application.war EAP_HOME/standalone/deployments/

자동 배포가 활성화되면 이 파일이 자동으로 선택되고 배포되고 .deployed 마커 파일이 생성됩니다. 자동 배포가 활성화되지 않은 경우 배포를 트리거하려면 .dodeploy 마커 파일을 수동으로 추가해야 합니다.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

애플리케이션 배포 취소

.deployed 마커 파일을 제거하여 배포 취소를 트리거합니다.

$ rm EAP_HOME/standalone/deployments/test-application.war.deployed

자동 배포가 활성화된 경우 test-application.war 파일을 제거하여 배포 취소를 트리거할 수도 있습니다. 이는 불합리한 배포에는 적용되지 않습니다.

애플리케이션 재배포

.dodeploy 마커 파일을 생성하여 재배포를 시작합니다.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

배포 스캐너는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다. 검사 간격, 배포 폴더 위치, 특정 애플리케이션 파일 유형의 자동 배포와 같은 배포 스캐너의 동작을 구성할 수 있습니다. 배포 스캐너를 완전히 비활성화할 수도 있습니다.

사용 가능한 모든 배포 스캐너 속성에 대한 자세한 내용은 Deployment Scanner Attributes 섹션을 참조하십시오.

아래 관리 CLI 명령을 사용하여 기본 배포 스캐너를 구성합니다.

배포 스캐너 비활성화

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)

이렇게 하면 기본 배포 스캐너가 비활성화됩니다.

검사 간격 변경

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=10000)

이렇게 하면 검사 간격 시간이 5000 밀리초(five 초)에서 10000 밀리초(10초)로 업데이트됩니다.

배포 폴더 변경

/subsystem=deployment-scanner/scanner=default:write-attribute(name=path,value=/path/to/deployments)

이렇게 하면 배포 폴더의 위치가 EAP_HOME/standalone/deployments 의 기본 위치에서 /path/to /deployments 로 변경됩니다.

relative-to 특성이 지정되지 않는 한 경로 값은 절대 경로로 취급되며 이 경우 해당 경로를 기준으로 합니다.

Exploded 콘텐츠의 자동 배포 활성화

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)

이를 통해 의심 스러운 콘텐츠를 자동으로 배포할 수 있으며 이는 기본적으로 비활성화되어 있습니다.

Zipped 콘텐츠의 자동 배포 비활성화

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-zipped,value=false)

이렇게 하면 기본적으로 활성화되어 있는 zipped 콘텐츠의 자동 배포가 비활성화됩니다.

XML 콘텐츠의 자동 배포 비활성화

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-xml,value=false)

이렇게 하면 기본적으로 활성화되어 있는 XML 콘텐츠의 자동 배포가 비활성화됩니다.

관리 CLI를 사용하여 새 배포 스캐너를 추가하거나 관리 콘솔의 구성 탭에서 Deployment Scanners 하위 시스템으로 이동하여 추가할 수 있습니다. 그러면 배포를 스캔할 새 디렉터리가 정의됩니다. 기본 배포 스캐너는 EAP_HOME/standalone/deployments 를 모니터링합니다. 기존 배포 스캐너 구성에 대한 자세한 내용은 배포 스캐너 구성을 참조하십시오.

다음 관리 CLI 명령은 배포에 대해 5초마다 EAP_HOME/standalone/new_deployment_dir 을 확인하는 새 배포 스캐너를 추가합니다.

/subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)

새 배포 스캐너가 정의되고 지정된 디렉터리가 배포에 대해 모니터링됩니다.

WildFly Maven 플러그인을 사용하여 독립 실행형 서버로 실행되는 JBoss EAP에 애플리케이션을 배포하고 배포 취소할 수 있습니다.

WildFly Maven 플러그인을 사용하여 관리형 도메인으로 실행되는 JBoss EAP에 애플리케이션을 배포하고 배포 취소할 수 있습니다.

WFLYUT0022: Unregistered web context: /helloworld
WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 106ms
WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")

기본적으로 HTTP API는 http://HOST:PORT/management 에서 액세스할 수 있습니다(예: http://localhost:9990/management ).

$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}]},{"operation" : "deploy", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "test-application.war"}},{"operation" : "remove", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

JSON 요청을 프로그래밍 방식으로 생성하는 방법에 대한 자세한 내용은 Red Hat Knowledgebase 문서를 참조하십시오.

HTTP API를 사용하여 관리형 도메인에 애플리케이션을 배포하고 배포를 취소할 수 있습니다.

배포된 콘텐츠를 저장할 JBoss EAP의 사용자 지정 위치를 정의할 수 있습니다.

독립 실행형 서버에 대한 사용자 지정 디렉터리 정의

기본적으로 독립 실행형 서버에 배포된 콘텐츠는 EAP_HOME/standalone/data/content 디렉터리에 저장됩니다. 이 위치는 서버를 시작할 때 -Djboss.server.deploy.dir 인수를 전달하여 변경할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content

선택한 위치는 JBoss EAP 인스턴스 간에 고유해야 합니다.

관리형 도메인에 대한 사용자 정의 디렉터리 정의

기본적으로 관리형 도메인에 배포된 콘텐츠는 EAP_HOME/domain/data/content 디렉터리에 저장됩니다. 이 위치는 도메인을 시작할 때 -Djboss.domain.deployment.dir 인수를 전달하여 변경할 수 있습니다.

$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content

선택한 위치는 JBoss EAP 인스턴스 간에 고유해야 합니다.

JBoss EAP는 서버 시작 시 배포 순서에 대한 세분화된 제어를 제공합니다. 다시 시작한 후 주문의 지속성과 함께 여러 EAR 파일에 있는 애플리케이션 배포 엄격한 순서를 지정할 수 있습니다.

jboss-all.xml 배포 설명자를 사용하여 최상위 배포 간에 종속성을 선언할 수 있습니다.

예를 들어 먼저 배포되는 framework.ear 에 따라 app.ear 가 있는 경우 아래 표시된 대로 app.ear/META-INF/jboss-all.xml 파일을 생성할 수 있습니다.

<jboss xmlns="urn:jboss:1.0">
  <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
    <dependency name="framework.ear" />
  </jboss-deployment-dependencies>
</jboss>

이렇게 하면 framework.ear 가 app.ear 앞에 배포됩니다.

관리형 도메인에서 도메인 또는 호스트 수준 리소스를 대상으로 하는 작업은 여러 서버에 영향을 미칠 수 있습니다. 이러한 작업에는 작업이 서버에 적용되는 시퀀스를 자세히 설명하는 롤아웃 계획과 일부 서버에서 성공적으로 실행되지 않으면 작업을 되돌릴 수 있는지 여부를 자세히 설명하는 정책이 포함될 수 있습니다. 롤아웃 계획을 지정하지 않으면 기본 롤아웃 계획이 사용됩니다.

{"my-rollout-plan" => {"rollout-plan" => {
    "in-series" => [
        {"concurrent-groups" => {
            "group-A" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-B" => undefined
        }},
        {"server-group" => {"group-C" => {
            "rolling-to-servers" => "false",
            "max-failed-servers" => "1"
        }}},
        {"concurrent-groups" => {
            "group-D" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-E" => undefined
        }}
    ],
    "rollback-across-groups" => "true"
}}}

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]

deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}

rollout-plan remove --name=my-rollout-plan

검색 콘텐츠 작업을 사용하여 관리 배포에서 파일 및 디렉터리를 확인합니다. 전체 배포 구조를 반환하거나 path 인수를 사용하여 특정 디렉터리의 경로를 제공하는 인수를 제공하지 않습니다.

/deployment=helloworld.war:browse-content(path=META-INF/)

그러면 helloworld.war 배포의 META-INF/ 디렉터리에 파일 및 디렉터리가 표시됩니다.

{
    "outcome" => "success",
    "result" => [
        {
            "path" => "MANIFEST.MF",
            "directory" => false,
            "file-size" => 827L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.properties",
            "directory" => false,
            "file-size" => 106L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.xml",
            "directory" => false,
            "file-size" => 2713L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/",
            "directory" => true
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/",
            "directory" => true
        },
        {
            "path" => "maven/",
            "directory" => true
        },
        {
            "path" => "INDEX.LIST",
            "directory" => false,
            "file-size" => 251L
        }
    ]
}

browse-content 작업에 다음 인수를 지정할 수도 있습니다.

read-content 작업을 사용하여 관리 배포에서 파일의 내용을 읽을 수 있습니다. 전체 배포를 반환하거나 path 인수를 사용하여 특정 파일의 경로를 제공하는 인수를 제공하지 않습니다. 예를 들면 다음과 같습니다.

/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

그러면 관리 CLI에 표시 하거나 파일 시스템에 저장할 수 있는 파일 스트림이 반환됩니다.

{
    "outcome" => "success",
    "result" => {"uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95"},
    "response-headers" => {"attached-streams" => [{
        "uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95",
        "mime-type" => "text/plain"
    }]}
}

attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

ATTACHMENT 8af87836-2abd-423a-8e44-e731cc57bd80:
Manifest-Version: 1.0
Implementation-Title: Quickstart: helloworld
Implementation-Version: 7.4.0.GA
Java-Version: 1.8.0_131
Built-By: username
Scm-Connection: scm:git:git@github.com:jboss/jboss-parent-pom.git/quic
 kstart-parent/helloworld
Specification-Vendor: JBoss by Red Hat
...

attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF